[High] Standalone hve-core omits a required skill

Problem: This package exposes both ADO commands, but its skills list does not include backlog-management. Both commands require that skill and stop before any Azure DevOps call when it cannot resolve, so the standalone hve-core installation advertises commands that deterministically fail.

Suggested fix: Add skills/project-planning/backlog-management and its recipe closure to hve-core, or move these commands to a package that already supplies the dependency. Add a package-closure test that resolves every command's named skill dependencies in each package that exposes it.

[High] Jira setup audit can expose live credentials

Problem: printenv | grep -i JIRA prints complete values for JIRA_API_TOKEN or JIRA_PAT before presentation-layer masking can apply. Terminal output is visible to the agent and may be retained in chat or debug logs, exposing a reusable tracker credential.

Suggested fix: Probe an explicit allowlist of variable names and emit only SET or MISSING. Never print token values or prefixes. Add a sentinel-token test asserting that credentials never appear in stdout, stderr, chat output, or audit logs.

[High] Jira dotenv loading executes configuration as shell code

Problem: Sourcing ~/.jira.env executes substitutions, redirections, and arbitrary commands from a user-writable file in a terminal that holds Jira credentials and repository access. A modified or malformed file can therefore execute code or exfiltrate secrets during setup.

Suggested fix: Parse an allowlisted KEY=VALUE format without shell evaluation, reject unknown or duplicate keys and shell metacharacters, pass values directly to the Jira subprocess environment, and require owner-only permissions. Test $(), backticks, semicolons, redirections, and embedded newlines.

[High] The read-only Functional Planner retains arbitrary shell authority

Problem: The planner is described as strictly read-only but receives execute/runInTerminal. It consumes untrusted PRDs, tracker bodies, comments, and web content, so prompt injection can induce shell commands, credential reads, or Jira mutations. The enforceable capability boundary is broader than the documented role.

Suggested fix: Remove terminal execution and terminal-output access. Route Jira reads through a constrained structured interface exposing only search, get, comments, and fields. Add an adversarial test proving that shell and mutation capabilities are unavailable, not merely refused in prose.

[High] The Jira executor's CLI-only policy is not enforced

Problem: execute/runInTerminal grants a general shell while the executor relies on prose to limit it to scripts/jira.py. The executor processes untrusted dispatches, Jira bodies, comments, and CLI output while credentials are present, so injected content can request arbitrary commands or cross-system actions.

Suggested fix: Replace shell access with a dedicated Jira tool wrapper using structured arguments and direct process invocation. Enforce a command allowlist, argument separation, destination checks, bounded output, and credential redaction. If that boundary cannot be provided, do not expose this executor as write-capable.

[High] ADO mutations are not bound to the confirmed project

Problem: Contract validation checks that a destination exists and the verb is supported, but it does not prove that each numeric System.Id or relationship endpoint belongs to the confirmed project. A stale or attacker-influenced handoff can mutate an accessible item in another project while reporting the confirmed destination.

Suggested fix: Hydrate every existing target and relationship endpoint before mutation and verify System.TeamProject matches the confirmed project. Require the confirmed project on creates, reject mismatches and dependent operations, and record the verified binding in the operation log.

[High] Jira mutations are not bound to the confirmed project key

Problem: Validation checks only that a project key is present and a CLI command exists. Existing issue keys and create payloads are not required to match the confirmed project, so a handoff confirmed for one project can update, transition, comment on, or create content in another project when the credential has access.

Suggested fix: Normalize the confirmed key, require every existing issue key and hydrated issue project to match it, and require every create payload's fields.project.key to match. Reject the operation set before the first mutation on any mismatch, with tests for create, update, transition, and comment.

[P1] Keep dry-run state out of resumable execution records

Dry runs write simulated Create results and {{TEMP-N}} -> (dry-run) mappings into handoff-logs.md, but resume rebuilds temporary-ID mappings from completed Create entries in that same log. A subsequent live run can therefore treat simulated work as complete or substitute (dry-run) into a child, link, or other dependent operation; the current sanitization rules do not reject that value.

Suggested fix: write dry-run entries to a separate Dry Run Log section, never to the Operation Log or the Temporary ID Mapping section; rebuild the mapping only from Operation Log entries with status Success; add a stop rule for a mapping that resolves any placeholder to a simulated key.

[P1] Use one durable resume predicate

The protocol currently resumes from the first unchecked operation here, from the first unlogged operation in backlog-execute, and from the first unchecked or unlogged operation in the core skill. Because Step 2 checks handoff.md before appending its log entry, an interruption in that window leaves the operation checked but unlogged: one path skips it while another reruns it, including a completed Create.

Suggested fix: Please make successful live entries in handoff-logs.md the sole resume authority, append that entry before updating the checkbox, and reconcile all three descriptions to the same rule.

[P1] Materialize triage recommendations into an execution handoff

This path names backlog-execute run <triage-plan.md>, but triage-plan.md has no operation checkboxes, stable <PREFIX>NNN references, verb-ordered sections, or temporary-ID allocations. The execution protocol therefore cannot initialize, resume, resolve dependencies, or mark a triage run complete consistently.

Suggested fix: Have Triage Phase 2 materialize its recommendations into a standard handoff.md with the required operation sections, reference IDs, checkboxes, and temporary IDs, then name backlog-execute run <handoff.md> as the execution path after review. triage-plan.md should remain analysis, not an execution contract.

[P1] Add an explicit upstream-review gate to generated handoffs

backlog-execute halts only on an unchecked human-review checkbox, but this shared template creates no such checkbox—only unchecked operation entries. As a result, locally generated handoffs bypass the upstream-review requirement; treating the operation boxes as review gates would instead halt every new run.

Suggested fix: Please add a dedicated ## Human Review or ## User Signoff section (for example, - [ ] Reviewed and validated by a qualified human reviewer) and require that specific checkbox to be checked before execution, while leaving operation checkboxes as execution state only.

[P2] Centralize executor-common constraints to prevent drift

The three executor agents repeat several shared execution constraints and the same handoff-logs.md path-formatting rule, despite backlog-execute being described as the shared mutating protocol.

Suggested fix: Please move the truly platform-neutral rules—including executor-authored-text sanitization, untrusted-content handling, shortcut prohibition, operation logging, and workspace-path formatting—into backlog-execute, then have each executor reference that protocol while retaining only its platform-specific deltas.

[P2] Dispatch PRD Planning to the same target named everywhere else

The handoff definition and PRD-planning classification identify Functional Planner as the target, but this dispatch row routes to the functional-planner skill instead. Agents and skills have different execution surfaces and contracts, so this leaves the actual PRD-planning path ambiguous.

Suggested fix: Please make this row dispatch to the Functional Planner agent, or change the other references if the skill is intended to be the sole entry point.

Question: Is the unbounded rate-limit retry intentional? This row requires exponential-backoff retries but, unlike the transient-network-failure row below, does not define a maximum attempt count, total wait budget, or terminal outcome when the platform remains rate-limited. If retries are intentionally indefinite, could we document that explicitly and explain how the user regains control? Otherwise, should this cap retries/wait time and abort or block the run while preserving handoff-logs.md for resumption?

[P2] Reconcile the Project Planning agent count with its landing page

This catalog says Project Planning contains 9 agents, but the linked Project Planning page says “Four agents” and lists only four in its Agent Overview. The surrounding catalog prose also implies a broader capability set than that page documents.

Suggested fix: Please align the count and the group page’s inventory so users can tell which agents are included in this category.

[P2] Define the source for in the shared binding table

The templates require substituting , but this binding table has no reference-ID-prefix row. The values only appear later in each platform reference (WI, IS, and JI), so a consumer following this file’s stated resolution path cannot derive the template IDs.

Suggested fix: Please add a Reference-ID prefix binding here, or explicitly direct resolution to the Platform Bindings table in the active platform reference.